LGTM

Seems good if it works! Just thinking through the implications here for a sec… this pass disables all our "automatic initialization" stuff when generating Verilog but only for Xilinx execution. I hope that none of the code is relying on any kind of initialization… @andrewb1999's original advice in #1071 suggests that it was not necessary to get things working:

It's a bad idea to initialize logic (especially resets) that are used as wires rather than registers. I just commented out the entire initial block in the verilog which prevented issues with std_regs not being reset properly (currently none of the logic defined in the main module is being used as a register so this is fine to do).

But I wonder if this doesn't actually indicate a deeper problem. Namely, perhaps the initialization we're doing is wrong not just in a Xilinx context but for all Verilog generation—and we just need to back off on some of that altogether. It would take a little more digging into how we currently initialize things to know for sure, but perhaps there's a subtler change to be made here.

I would still recommend (1) forging ahead with this PR as-is, if it actually seems to improve things for Xilinx execution, and then (2) revisiting this broader "is our initialization stuff correct?" question later, with a goal toward removing the special --disable-init treatment in this stage.

Yeah to be clear I think this is an issue with the verilog initialization in all cases, not just Xilinx. I think this is a case where different simulators/compilers will behave differently on something akin to undefined behavior in the systemverilog spec.

A good example of this behavior in the fsm_reset logic. It appears in three places in the dot-product.sv file, declaration, initialization to 0, and combinational assignment to the reset wire (assign fsm_reset = reset). Initialization only really makes sense in the context of registers (aka logic that is assigned to sequentially in an always block). In the Xilinx simulator, fsm_reset is always 0, the value it was initialized to, instead of getting set to 1 when reset is 1. I think this is some case of Xilinx getting confused because in one place it looks like we use fsm_reset as a register (initialization) and in another place we use it as a wire (combinational assignment with assign).

Other simulators may handle this situation differently, but it is certainly the case that if we remove the initialization of fsm_reset, all simulators will behave the same by making fsm_reset the same wire net as reset.

That being said, I agree with @sampsyo that this PR is a good starting place and we can come back to fixing the core issue with initialization later.